Séparation des couleurs dans un lambda-calcul bichrome

National audienceDans cet article nous introduisons un λ-calcul bichrome pour expliciter une partie de l'évaluation d'un terme en précisant la localité du calcul1. L'intérêt est alors de pouvoir définir une transformation, par β-expansion, qui regroupe les expressions de même couleur. Les propriétés de correction, de terminaison et de confluence de cette transformation sont démontrées 'a l'aide de l'assistant de preuves Coq. Cette transformation est indépendante de la sémantique de communication et de synchronisation de l'application. On s'intéresse alors aux applications utilisant deux unités de calcul comme les couples client-serveur de la programmation Web. Nous abordons le passage à un λ-calcul à plus de deux couleurs et montrons les difficultés que cela engendre

Unification des couleurs dans un lambda-calcul polychrome

National audienceDans cet article nous étendons le lambda-calcul bi-chrome présenté aux JFLA 2012 pour y introduire la polychromie. On définit une nouvelle transformation, par beta-expansion, qui regroupe les expressions de même couleur, chaque couleur pouvant représenter une unité de calcul. On ne se contente plus de pouvoir expliciter la localité d'un calcul dans un modèle à deux couleurs comme pour les clients-serveurs mais nous pouvons traiter les applications multi-tiers. Les propriétés de correction, de terminaison et de confluence de cette nouvelle transformation sont démontrées à l'aide de Coq

Benchmarking implementations of functional languages with ‘Pseudoknot', a float-intensive benchmark

Over 25 implementations of different functional languages are benchmarked using the same program, a floating-point intensive application taken from molecular biology. The principal aspects studied are compile time and execution time for the various implementations that were benchmarked. An important consideration is how the program can be modified and tuned to obtain maximal performance on each language implementation. With few exceptions, the compilers take a significant amount of time to compile this program, though most compilers were faster than the then current GNU C compiler (GCC version 2.5.8). Compilers that generate C or Lisp are often slower than those that generate native code directly: the cost of compiling the intermediate form is normally a large fraction of the total compilation time. There is no clear distinction between the runtime performance of eager and lazy implementations when appropriate annotations are used: lazy implementations have clearly come of age when it comes to implementing largely strict applications, such as the Pseudoknot program. The speed of C can be approached by some implementations, but to achieve this performance, special measures such as strictness annotations are required by non-strict implementations. The benchmark results have to be interpreted with care. Firstly, a benchmark based on a single program cannot cover a wide spectrum of ‘typical' applications. Secondly, the compilers vary in the kind and level of optimisations offered, so the effort required to obtain an optimal version of the program is similarly varie

PRATIQUE DES LANGAGES FONCTIONNELS TYPES

COUSINEAU GUY (Président), GOLDBERG BENJAMIN (Rapporteur), MAUNY MICHEL (Rapporteur), QUEINNEC CHRISTIAN (Rapporteur), HAINS GAETAN (Examinateur), MOREL ETIENNE (Examinateur)PRATIQUE DES LANGAGES FONCTIONNELS TYPES Dans l'approche conception on s'intéresse à l'évolution de la compilation de ML en l'illustrant par la description de deux compilateurs : CeML un compilateur de ML vers C et OCamil un compilateur d'O'CAML vers .net. On montre ensuite les capacités d'extensions (parallèle et objet) au niveau des constructions du langage ML. Cela autorise de le choisir comme langage cible de compilation pour d'autres langages. Les capacités d'interopérer entre ML d'autres langages sont alors explorées pour plusieurs plates-formes d'exécution en conservant la sûreté du typage statique. Dans l'approche développement d'applications on s'intéresse aux outils de développement de l'édition structurée à la mise au point et à l'intégration de ces outils dans une même interface. On discute ensuite sur la formation du programmeur en montrant le cadre confortable du typage statique et l'intérêt de comprendre le modèle fonctionnel avant d'aborder le modèle objet. Le déploiement d'application est illustré par plusieurs applications embarquant un compilateur ML en tant que composant de l'application

Compilation des langages fonctionnels: CeML un traducteur de ML vers C

SIGLEAvailable from INIST (FR), Document Supply Service, under shelf-number : T 84284 / INIST-CNRS - Institut de l'Information Scientifique et TechniqueFRFranc